在Day-15: 多節點的OpenStack環境建OpenStack時，有一個特殊的設定--os-neutron-ml2-type-drivers=flat。這個作用是當採用OVN mechanism做為neutron的網路方案時，建立Tenant Network時，除了昨天提到的geneve type Network外，還仍可以選擇flat Network。Flat Network的特性是instance跨節點互相通訊時，會直接透過mapping的interface溝通，而不會經過Geneve Tunnel. 甚至，VM也可以透過Flat Network與實體網路上的主機通訊。

建立flat Tenant Network

1. 建立 Flat Tenant Network

openstack network create --provider-network-type flat --provider-physical-network flat0  n1
openstack subnet create --subnet-range 192.168.10.0/24 --network n1 n1subnet

建立Flat Network時，必需透過--provider-physical-network指定要使用的實體網路名稱。這裡使用flat0是因為packstack的--os-neutron-ovn-bridge-mappings=extnet0:br-ex,flat0:br-eth2參數指明flat0會使用br-eth2這個bridge。

2. 建立server group

openstack server group create --policy affinity      odd_affinity
openstack server group create --policy anti-affinity odd_anti_affinity

3. 建立instance

IMAGE_ID=$(openstack image show cirros --format json | jq -r .id)
AFFINITY_ID=$(openstack server group show  odd_affinity  --format json | jq -r .id)
ANTI_AFFINITY_ID=$(openstack server group show  odd_anti_affinity --format json | jq -r .id)

openstack server create --nic net-id=n1,v4-fixed-ip=192.168.10.111 --flavor m1.nano --image $IMAGE_ID --hint group=$AFFINITY_ID      vm_1
openstack server create --nic net-id=n1,v4-fixed-ip=192.168.10.222 --flavor m1.nano --image $IMAGE_ID --hint group=$ANTI_AFFINITY_ID vm_2

4. 建立Security Group

# create sg for icmp
openstack security group create allow-icmp
openstack security group rule create --protocol icmp --remote-ip 0.0.0.0/0 allow-icmp

# add sg to instances
openstack server add security group vm_1 allow-icmp
openstack server add security group vm_2 allow-icmp

在之前，我們要測試VM間的連通性，都不用特別建立security group來放行相對應的封包，主因是在OpenStack，同一個Network下的VM是可以互相通訊的。在採用Flat Network時，VM和位在同一個實體網路的的實體機器是能夠互相通訊，但是為了讓實體機器和VM相通訊的話，則必需加上額外的security group。

5. 查看OpenStack上Network 與 Port的資訊，確實與圖中預期要建立的長像是相同的

# Network
openstack network  list --long -c ID -c "Network Type" | abbrev

+--------+--------------+
| ID     | Network Type |
+--------+--------------+
| 765501 | flat         |
+--------+--------------+

openstack port  list --long -c ID -c "Fixed IP Addresses" -c "Device Owner" | abbrev

+--------+-------------------------------------------------+---------------------+
| ID     | Fixed IP Addresses                              | Device Owner        |
+--------+-------------------------------------------------+---------------------+
| bc3d8c | ip_address='192.168.10.111', subnet_id='307767' | compute:nova        |
| 565b06 | ip_address='192.168.10.222', subnet_id='307767' | compute:nova        |
| 0b6d29 | ip_address='192.168.10.2', subnet_id='307767'   | network:distributed |
+--------+-------------------------------------------------+---------------------+

OpenStack 與OVN 元件關係

查看North Bound DB的情況

• 有一個neutron-765501 logical switch
• logical switch上有四個port, bc3d8c、565b06、provnet-91d8f、0b6d29，其中0b6d29是localport，provnet-91d8f是localnet。

ovn-nbctl show| abbrev

switch f4b3be (neutron-765501) (aka n1)
    port 565b06
        addresses: ["fa:16:3e:63:dc:f9 192.168.10.222"]
    port 0b6d29
        type: localport
        addresses: ["fa:16:3e:95:ae:f7 192.168.10.2"]
    port bc3d8c
        addresses: ["fa:16:3e:3c:da:b8 192.168.10.111"]
    port provnet-91d8f
        type: localnet
        addresses: ["unknown"]

我們可以發現North Bound DB查得的logical switch的資訊，與OpenStack上Network的資訊，與昨天[[Day-16_Geneve-Network-Connectivity]]的說明相同，

1. OpenStack Network的ID765501和OVN logical switchneutron-765501相呼應
2. OpenStack Network裡用到的Port,都會出現在OVN的logical switch上
   • Network一建立，有0b6d29 port ，attached device是network:distributed
   • instance建立後，會新增attached device是compute:nova的port

但是採用Flat Network時，可以看到logical switch上多建立一個localnet type的logical switch port, 依 Day-06: 連接虛擬與實體網路的localnet switch的說明，localnet是用來連接logical switch 和實體網路。可以查得localnetport 使用的實體網路名稱為flat0。

$ ovn-nbctl --column options list logical_switch_port provnet-91d8f40e-1273-4a05-9a94-53fc3566e0c6

options             : {mcast_flood="false", mcast_flood_reports="true", network_name=flat0}

localnet在OpenStack上並沒有相對應的port存在。

OVN logical switch 和 compute node的關係

建立二個instances後，查到compute node上bridge的情況。

因為今天的說明不會提到network-controller 節點與 eth0這張NIC，所以我們把這些資訊從圖中省略。

1. 查看South Bound DB, 這裡的結果的分析，和昨天介紹Geneve Network的說明完全相同，不再重復。
2. 到每個compute node上，透過ovs查看logical port和compute node上link的對應關係.
   • 和Flat Network有關係的是 br-int 與 br-eth2 這二個bridge。
   • br-int的長像和geneve network時產生的br-int雷同，只是多了 patch-br-int-to-provnet-91d8f4 port。除了這個新的port之外，其餘的port與logical switch port的mapping的說明，都與昨天的geneve network完全相同。
   • br-eth2有eth2與patch-provnet-xxx-to-br-int二個port
     • eth2 port 和實體eth2網卡連通
   • br-int 與 br-eth2是透過個別patch-br-int-to-provnet-91d8f4與patch-provnet-91d8f4-to-br-int 將二個bridge連通

   $ ovs-vsctl  show
       Bridge br-eth1
           fail_mode: standalone
           Port patch-provnet-91d8f40e-1273-4a05-9a94-53fc3566e0c6-to-br-int
               Interface patch-provnet-91d8f40e-1273-4a05-9a94-53fc3566e0c6-to-br-int
                   type: patch
                   options: {peer=patch-br-int-to-provnet-91d8f40e-1273-4a05-9a94-53fc3566e0c6}
           Port eth1
               Interface eth1
           Port br-eth1
               Interface br-eth1
                   type: internal
   

連通性討論

因為建立的flat network，選用flat0 physical network，而flat0和bridge的mapping為flat0:br-eth2，又因為br-eth2和interface的對應為br-eth2:eth2，所以這個flat type的private network的封包會經由eth2傳送。而不會經由eth1透過tunnel傳送。

$ tcpdump -i eth2 icmp
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
06:27:23.324829 IP 192.168.10.222 > 192.168.10.111: ICMP echo request, id 56026, seq 1, length 64
06:27:23.327376 IP 192.168.10.111 > 192.168.10.222: ICMP echo reply, id 56026, seq 1, length 64

其實我們也可以依昨天的介紹，試著在ovn-a17b40-0、tapbc3d8ce1-fb、genev_sys_6081、eth1 等 geneve 流量會經過的interface抓封包，會發覺使用flat network時，跨節點的流量是不會透過geneve傳送。這部份就讓大家自己確認囉。

今天介紹的Flat Network 看起來好像非常複雜，但是如果從昨天開始理解，有一半的架構是和昨天相同，差別只在跨節點通訊時，不是用Geneve, 而是直接透過eth2。